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Abstract. Cminor is a mid-level imperative programming language; 
there are proved-correct optimizing compilers from C to Cminor and 
from Cminor to machine language. We have redesigned Cminor so that 
it is suitable for Hoare Logic reasoning and we have designed a Sepa- 
ration Logic for Cminor. In this paper, we give a small-step semantics 
(instead of the big-step of the proved-correct compiler) that is moti- 
vated by the need to support future concurrent extensions. We detail 
a machine-checked proof of soundness of our Separation Logic. This is 
the first large-scale machine-checked proof of a Separation Logic w.r.t. a 
small-step semantics. The work presented in this paper has been carried 
out in the Coq proof assistant. It is a first step towards an environment 
in which concurrent Cminor programs can be verified using Separation 
Logic and also compiled by a proved-correct compiler with formal end- 
to-end correctness guarantees. 



1 Introduction 

The future of program verification is to connect machine-verified source pro- 
grams to machine- verified compilers, and run the object code on machine- verified 
hardware. To connect the verifications end to end, the source language should 
be specified as a structural operational semantics (SOS) represented in a log- 
ical framework; the target architecture can also be specified that way. Proofs 
of source code can be done in the logical framework, or by other tools whose 
soundness is proved w.r.t. the SOS specification; these may be in safety proofs 
via type-checking, correctness proofs via Hoare Logic, or (in source languages 
designed for the purpose) correctness proofs by a more expressive proof theory. 
The compiler — if it is an optimizing compiler — will be a stack of phases, each 
with a well specified SOS of its own. There will be proofs of (partial) correctness 
of each compiler phase, or witness-driven recognizers for correct compilations, 
w.r.t. the SOS's that are inputs and outputs to the phases. 

Machine- verified hardware/compiler/application stacks have been built be- 
fore. Moore described a verified compiler for a "high-level assembly language" 
[13]. Leinenbach et al. [11] have built and proved a compiler for CO, a small 
C-like language, as part of a project to build machine-checked correctness proofs 
of source programs, Hoare Logic, compiler, micro-kernel, and RISC processor. 
These are both simple one- or two-pass nonoptimizing compilers. 
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Leroy [12] has built and proved correct in Coq [1] a compiler called CompCert 
from a high-level intermediate language Cminor to assembly language for the 
Power PC architecture. This compiler has 4 intermediate languages, allowing 
optimizations at several natural levels of abstraction. Blazy et al. have built and 
proved correct a translator from a subset of C to Cminor [5]. Another compiler 
phase on top (not yet implemented) will then yield a proved-correct compiler 
from C to machine language. We should therefore reevaluate the conventional 
wisdom that an entire practical optimizing compiler cannot be proved correct. 

A software system can have components written in different languages, and 
we would like end-to-end correctness proofs of the whole system. For this, we pro- 
pose a new variant of Cminor as a machine-independent intermediate language 
to serve as a common denominator between high-level languages. Our new Cmi- 
nor has a usable Hoare Logic, so that correctness proofs for some components 
can be done directly at the level of Cminor. 

Cminor has a "calculus-like" view of local variables and procedures (i.e. local 
variables are bound in an environment), while Lcincnbach's CO has a "storage- 
allocation" view (i.e. local variables are stored in the stack frame). The calculus- 
like view will lead to easier reasoning about program transformations and easier 
use of Cminor as a target language, and fits naturally with a multi-pass optimiz- 
ing compiler such as CompCert; the storage-allocation view suits the one-pass 
nonoptimizing CO compiler and can accommodate in-line assembly code. 

Cminor is a promising candidate as a common intermediate language for 
end-to-end correctness proofs. But we have many demands on our new variant 
of Cminor, only the first three of which are satisfied by Leroy's Cminor. 

• Cminor has an operational semantics represented in a logical framework. 

• There is a proved-correct compiler from Cminor to machine language. 

• Cminor is usable as the high-level target language of a C compiler. 

o Our semantics is a small-step semantics, to support reasoning about in- 
put/output, concurrency, and nontermination. 

o Cminor is machine-independent over machines in the "standard model" (i.e. 
32- or 64-bit single-address-space byte- addressable multiprocessors). 

o Cminor can be used as a mid-level target language of an ML compiler [8] , or 
of an OO-language compiler, so that we can integrate correctness proofs of 
ML or 00 programs with the proofs of their run-time systems and libraries. 

o As we show in this paper, Cminor supports an axiomatic Hoare Logic (in fact, 
Separation Logic), proved sound with respect to the small-step semantics, 
for reasoning about low-level (C-like) programs. 

o In future work, we plan to extend Cminor to be concurrent in the "stan- 
dard model" of thread-based preemptive lock-synchronized weakly consistent 
shared-memory programming. The sequential soundness proofs we present 
here should be reusable in a concurrent setting, as we will explain. 

Leroy's original Cminor had several Power-PC dependencies, is slightly clumsy 
to use as the target of an ML compiler, and is a bit clumsy to use in Hoare-stylc 
reasoning. But most important, Leroy's semantics is a big-step semantics that 
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can be used only to reason about terminating sequential programs. We have re- 
designed Cminor's syntax and semantics to achieve all of these goals. That part 
of the redesign to achieve target-machine portability was done by Leroy himself. 
Our redesign to ease its use as an ML back end and for Hoare Logic reasoning 
was fairly simple. Henceforth in this paper, Cminor will refer to the new version 
of the Cminor language. 

The main contributions of this paper are a small-step semantics suitable 
for compilation and for Hoare Logic; and the first machine-checked proof of 
soundness of a sequential Hoare Logic (Separation Logic) w.r.t. a small-step 
semantics. Schirmer [17] has a machine-checked big-step Hoarc-Logic soundness 
proof for a control flow much like ours, extended by Klein et al. [10] to a C-likc 
memory model. Ni and Shao [14] have a machine-checked proof of soundness of 
a Hoare-like logic w.r.t. a small-step semantics, but for an assembly language 
and for much simpler assertions than ours. 

2 Big-step Expression Semantics 

The C standard [2] describes a memory model that is byte- and word-addressable 
(yet portable to big-endian and little-endian machines) with a nontrivial seman- 
tics for uninitialized variables. Blazy and Leroy formalized this model [6] for 
the semantics of Cminor. In C, pointer arithmetic within any malloc'ed block 
is defined, but pointer arithmetic between different blocks is undefined; Cmi- 
nor therefore has non-null pointer values comprising an abstract block-number 
and an int offset. A NULL pointer is represented by the integer value 0. Pointer 
arithmetic between blocks, and reading uninitialized variables, are undefined but 
not illegal: expressions in Cminor can evaluate to undefined (Vundef) without 
getting stuck. 

Each memory load or store is to a non-null pointer value with a "chunk" 
descriptor ch specifying number of bytes, signed or unsigned, int or float. Storing 
as 32-bit-int then loading as 8-bit-signed-byte leads to an undefined value. Load 

and store operations on memory, m h v\ h5 u 2 and ml = m[vi := v?], are partial 
functions that yield results only if reading (resp., writing) a chunk of type ch 

ch 

at address v\ is legal. We write m r v\ i— > v to mean that the result of loading 
from memory m at address V\ a chunk- type ch is the value v. 

The values of Cminor are undefined (Vundef), integers, pointers, and floats. 
The int type is an abstract data-type of 32-bit modular arithmetic. The expres- 
sions of Cminor are literals, variables, primitive operators applied to arguments, 
and memory loads. 

There are 33 primitive operation symbols op; two of these are for accessing 
global names and local stack-blocks, and the rest is for integer and floating-point 
arithmetic and comparisons. Among these operation symbols are casts. Cminor 
casts correspond to all portable C casts. Cminor has an infinite supply ident of 
variable and function identifiers id. As in C, there are two namespaces — each id 
can be interpreted in a local scope (using Evar(zd)) or in a global scope (using 
Eop with the operation symbol for accessing global names). 
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e : expr 
el : exprlist 



v 



i : int 



val 



[0,2 32 ) 

Vundef | Vint (i) | Vptr (b,i) | Vfloat (/) 
Eval (v) | Evar (id) | Eop (op, el) | Eload (ch,e) 
Enil | Econs (e, el) 



Expression Evaluation. In original Cminor, expression evaluation is expressed 
by an inductive big-step relation. Big-step statement execution is problematic 
for concurrency, but big-step expression evaluation is fine even for concurrent 
programs, since we will use the separation logic to prove noninterference. 

Evaluation is deterministic. Leroy chose to represent evaluation as a relation 
because Coq had better support for proof induction over relations than over 
function definitions. We have chosen to represent evaluation as a partial func- 
tion; this makes some proofs easier in some ways: f(x) — f(x) is simpler than 
fxy=^fxz^y~z. Before Coq's new functional induction tactic was avail- 
able, we developed special-purpose tactics to enable these proofs. Although we 
specify expression evaluation as a function in Coq, we present evaluation as a 
judgment relation in Fig. 1. Our evaluation function is (proved) equivalent to 
the inductively defined judgment (sp; p; (f>; m) h e JJ. v where: 
& is the "program," consisting of a global environment (ident — > option block) 
mapping identifiers to function-pointers and other global constants, and a 
global mapping (block — > option function) that maps certain ( "text-segment" ) 
addresses to function definitions. 
sp : block. The "stack pointer" giving the address and size of the memory 

block for stack-allocated local data in the current activation record. 
p : env. The local environment, a finite mapping from identifiers to values. 
: footprint. It represents the memory used by the evaluation of an expression 
(or a statement). It is a mapping from memory addresses to permissions. 
Leroy's Cminor has no footprints. 
m : mem. The memory, a finite mapping from blocks to block contents [6]. 
Each block represents the result of a C malloc, or a stack frame, a global 
static variable, or a function code-pointer. A block content consists of the 
dimensions of the block (low and high bounds) plus a mapping from byte 
offsets to byte-sized memory cells, 
e : expr. The expression being evaluated. 
v : val. The value of the expression. 

Loads outside the footprint will cause expression evaluation to get stuck. 
Since the footprint may have different permissions for loads than for stores to 
some addresses, we write <j> h loaded u (or <j> h storey v) to mean that all the 
addresses from v to v + \ch\ — 1 are readable (or writable). 

To model the possibility of exclusive read/ write access or shared read-only 
access, we write 0o © <h ~ § f° r the "disjoint" sum of two footprints, where © 
is an associative and commutative operator with several properties such as 0o ^ 
store c /j v 4>\ \f loadc/t v, (f>o h loaded v =^ (j) h load c ^ v and 4>o h storey v 
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t , i \ i i — i / \ i x <= domp 

W; (sp; p; <p; m) h Eval (v) JJ. n 



&;(sp; p;4>;m)\- Evar(s) i\- p(x) 

<P; (sp; p; <f>; m) h el JJ vl <P; sp h op(vl) JJ e „ a Lo P eration V 
&; (sp; p; cf>; m) h Eop (op, eZ) 4 « 



ch 



fy; (sp; p; cf>; m) h ei JJ. wi h load c h wi m h t)i h « 

if'; (sp; p; </>; m) h Eload (c/i, ei) J].?; 

Fig. 1. Expression evaluation rules 

cj) h store^f. One can think of as a set of fractional permissions [7], with 
meaning no permission, < x < 1 permitting read, and 1 giving read/write 
permission. A store permission can be split into two or more load permissions, 
which can be reconstituted to obtain a store permission. Instead of fractions, we 
use a more general and powerful model of sharablc permissions similar to one 
described by Parkinson [16, Ch. 5]. 

Most previous models of Separation Logic (e.g., Ishtiaq and O'Hcarn [9]) 
represent heaps as partial functions that can be combined with an operator like 
©. Of course, a partial function can be represented as a pair of a domain set 
and a total function. Similarly, we represent heaps as a footprint plus a Cminor 
memory; this does not add any particular difficulty to the soundness proofs for 
our Separation Logic. 

To perform arithmetic and other operations, in the third rule of Fig. 1, the 
judgment sp h op(vl) -IJ-evaLoperation v takes an operator op applied to a list of 
values vl and (if vl contains appropriate values) produces some value v. Operators 
that access global names and local stack-blocks make use of 3^ and sp respectively 
to return the address of a global name or a local stack-block address. 



States. We shall bundle together (sp; p; 4>; m) and call it the state, written as a. 
We write W; a h e J| v to mean &; (sp a ; p a ; 4> a ; m a ) h e JJ. v. 

Notation. We write a[:= p'] to mean the state a with its environment component 
p replaced by p', and so on (e.g. see rules 2 and 3 of Fig. 2 in Section 4). 

ch 

Fact. W; sp h op(vl) J| e vaLoperation v and m h vi t— > v are both deterministic 
relations, i.e. functions. 

Lemma 1. H/; a \- e 4J. v is a deterministic relation. (Trivial by inspection.) 
Lemma 2. For any value v, there is an expression e such that Vtr. (!?; a h e JJ. v). 



Proof. Obvious; e is simply Evalu. But it is important nonetheless: reasoning 
about programs by rewriting and by Hoare Logic often requires this property, and 
it was absent from Leroy's Cminor for Vundef and Vptr values. I 

An expression may fetch from several different memory locations, or from 
the same location several times. Because JJ. is deterministic, we cannot model a 
situation where the memory is updated by another thread after the first fetch 
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and before the second. But we want a semantics that describes real executions 
on real machines. The solution is to evaluate expressions in a setting where we 
can guarantee noninterference. We will do this (in our extension to Concurrent 
Cminor) by guaranteeing that the footprints <fi of different threads are disjoint. 

Erased Expression Evaluation. The Cminor compiler (CompCert) is proved cor- 
rect w.r.t. an operational semantics that does not use footprints. Any program 
that successfully evaluates with footprints will also evaluate ignoring footprints. 
Thus, for sequential programs where we do not need noninterference, it is sound 
to prove properties in a footprint semantics and compile in an erased semantics. 
We formalize and prove this in the full technical report [4] . 

3 Small-step Statement Semantics 

The statements of sequential Cminor are: 

s : stmt x := e [ei] ch :=e2 | loops | blocks | exitn 

| caWxleel | return el\ Si;s2 | if e then si else S2 | skip. 

The assignment x :~ e puts the value of e into the local variable x. The store 
[ei] c/l :=e 2 puts (the value of) e 2 into the memory-chunk ch at address given 
by (the value of) e\. (Local variables are not addressable; global variables and 
heap locations are memory addresses.) To model exits from nested loops, blocks 
runs s, which should not terminate normally but which should exitn from the 
(n+l) th enclosing block, and loop s repeats s infinitely or until it returns or exits, 
call xl e el calls function e with parameters (by value) el and results returned back 
into the variables xl. return el evaluates and returns a sequence of results, (si; S2) 
executes si followed by s 2 (unless Si returns or exits), and the statements if and 
skip are as the reader might expect. 

Combined with infinite loops and if statements, blocks and exits suffice to 
express efficiently all reducible control-flow graphs, notably those arising from 
C loops. The C statements break and continue arc translated as appropriate exit 
statements. Blazy et al. [5] detail the translation of these C statements into 
Cminor. 

Function Definitions. A program tf' comprises two mappings: a mapping from 
function names to memory blocks (i.e., abstract addresses), and a mapping from 
memory blocks to function definitions. Each function definition may be written as 
/ = (xl, yl, n, s), where params(J) = xl is a list of formal parameters, locals(/) = 
yl is a list of local variables, stackspace(/) = n is the size of the local stack-block 
to which sp points, and the statement body(/) = s is the function body. 

Operational Semantics. Our small-step semantics for statements is based on 
continuations, mainly to allow a uniform representation of statement execution 
that facilitates the design of lemmas. Such a semantics also avoids all search 
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rules (congruence rules), which avoids induction over search rules in both the 
Hoare-Logic soundness proof and the compiler correctness proof. 3 

Definition 1. A continuation k has a state a and a control stack n. There are 
sequential control operators to handle local control flow (Kseq, written as ■), in- 
traprocedural control flow (Kblock), and function-return (Kcall); this last carries 
not only a control aspect but an activation record of its own. The control operator 
Kstop represents the safe termination of the computation. 

K : control ::= Kstop | s ■ k | Kblock k | Kcall xl f sp pn 
k : continuation ::= (er, k) 

The sequential small-step function takes the form W h k i — ► k' (see Fig. 2), 
and we define as usual its reflexive transitive closure i — ►*. As in C, there is no 
boolean type in Cminor. In Fig. 2, the predicate is_truei> holds if v is a pointer or 
a nonzero integer; is_false holds only on 0. A store statement [e{\ ch :~e2 requires 
the corresponding store permission CT h storey v\. 

Given a control stack block s ■ k, the small-step execution of the block state- 
ment blocks enters that block: s becomes the next statement to execute and the 
control stack becomes s ■ Kblock k. 

Exit statements are only allowed from blocks that have been previously en- 
tered. For that reason, in the two rules for exit statements, the control stack 
ends with (Kblock k) control. A statement (exitn) terminates the (n + V) en- 
closing block statements. In such a block, the stack of control sequences s\ ■ ■ ■ Sj 
following the exit statement is not executed. Let us note that this stack may be 
empty if the exit statement is the last statement of the most enclosing block. 
The small-step execution of a statement (exitn) exits from only one block (the 
most enclosing one). Thus, the execution of an (exitO) statement updates the 
control stack (exit ■ Si • • • • Sj ■ Kblock k) into K. The execution of an (exit n + 1) 
statement updates the control stack (exit (n+1) - si - • • • Sj ■ Kblock k) into exit n-K. 

Lemma 3. If if - ; a h e JJ. v then & h (a, (x := e) • n) i — ► k' iff & h (a, (x := 
Eval v) ■ k)) i — > k' (and similarly for other statements containing expressions). 

Proof. Trivial: expressions have no side effects. A convenient property nonethe- 
less, and not true of Leroy 's original Cminor. ■ 

Definition 2. A continuation k = (a, k) is stuck if k =/= Kstop and there does 
not exist k' such that \P h k i — > k! . 

Definition 3. A continuation k is safe (written as \P h safe(fc)J if it cannot 
reach a stuck continuation in the sequential small-step relation i — ►*. 



3 We have proved in Coq the equivalence of this small-step semantics with the big-step 
semantics of CompCert (for programs that terminate). 
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if; a h e JJ, n p' = p CT [x := u] 

!f h (<7, (Si; S2) ■ ft) I > (cr, Si ■ S2 ■ ft) 



<f h (a, (x := e) • «) i— > (cr[:= £>'], «) 

If'; a h ei JJ. !f ; cr h e2 4 v 2 4><y ^ storey t;i m' = m CT [ui := U2] 

([ei] cft :=e 2 ) • k) .— ► (a[:=m'],«) 

<f; cr h e JJ- v is_true v 



!f h (a, (if e then si else S2) ■ ft) i — > (a,SfK 
i'jff h e |« is_false u 



9 h (cr, skip • k) i — > (ct, k) 



!f h (cr, (if e then si else S2) -ft) i — > (cr, S2 ■ ft) 
<f h (cr, (loop s) ■ ft) 1 — > (cr, s • loop s ■ ft) !f h (cr, (block s) ■ ft) 1 — > (cr, s ■ Kblock ft) 



!f h (cr, exit • si • • • • Sj ■ Kblock ft) 1 — > (<r, k) 



•f h (cr, exit (n + 1) • Si • • ■ • Sj ■ Kblock ft) 1 — > (cr, exit n ■ ft) 

Fig. 2. Sequential small-step relation. We omit here call and return, which are in the 
full technical report [4]. 



4 Separation Logic 



Hoare Logic uses triples {P} s {Q} where P is a precondition, s is a statement of 
the programming language, and Q is a postcondition. The assertions P and Q are 
predicates on the program state. The reasoning on memory is inherently global. 
Separation Logic is an extension of Hoare Logic for programs that manipulate 
pointers. In Separation Logic, reasoning is local [15]; assertions such as P and 
Q describe properties of part of the memory, and {P} s {Q} describes changes 
to part of the memory. We prove the soundness of the Separation Logic via a 
shallow embedding, that is, we give each assertion a semantic meaning in Coq. 
We have P, Q : assert where assert = prog — > state — > Prop. So PSPa is a 
proposition of logic and we say that a satisfies P. 



Assertion Operators. In Fig. 3, we define the usual operators of Separation Logic: 
the empty assertion emp, separating conjunction *, disjunction V, conjunction 
A, implication =>, negation -1, and quantifier 3. A state a satisfies P * Q if its 
footprint tp a can be split into <f>\ and 4>2 such that a[:= <j>i] satisfies P and 
a[:= 4>2\ satisfies Q. We also define some novel operators such as expression 
evaluation e JJ- v and base-logic propositions \A] . 

O'Hearn and Reynolds specify Separation Logic for a little language in which 
expressions evaluate independently of the heap [15]. That is, their expressions 
access only the program variables and do not even have read side effects on the 
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emp 


=dcf 


P*Q 


=de£ 


PvQ 


=def 


PAQ 


=def 


P^Q 


=def 


-^P 


=de£ 


3z.P 


=dcf 


\A] 


=dcf 


true 


=dcf 


e \\-v 


=dcf 


expr 


=dcf 


defined(e) 


=dcf 


ch 




ei ' * e 2 


=de£ 



\9a. Pa =>• Qa 
\<Pa. -.(Per) 
A^cr. 3z.Pa 

\tya. A where a does not appear free in A 
A^cr.True false = dcf [False] 

emp A fpure(e)] A Wa. (W; a h e JJ. v) 



r int 
=dcf | e == 



r float -, 

xpr V \e == e\ 



Fig. 3. Main operators of Separation Logic 



memory. Memory reads are done by a command of the language, not within 
expressions. In Cminor we relax this restriction; expressions can read the heap. 
But we say that an expression is pure if it contains no Eload operators — so that 
it cannot read the heap. 

In Hoare Logic one can use expressions of the programming language as 
assertions — there is an implicit coercion. We write the assertion e JJ. v to mean 
that expression e is pure and evaluates to value v in the operational semantics. 
This is an expression of Separation Logic, in contrast to !f ; a h e | i> which is 
a judgment in the underlying logic. In a previous experiment, our Separation 
Logic permitted impure expressions in e JJ- v. But, this complicated the proofs 
unnecessarily. Having emp A [pure(e)] in the definition of e JJ. v leads to an 
easier-to-use Separation Logic. 

Hoare Logic traditionally allows expressions e of the programming language 
to be used as expressions of the program logic. We will define explicitly [e] eX pr 
to mean that e evaluates to a true value (i.e. a nonzero integer or non-null 
pointer). Following Hoare's example, we will usually omit the [] eX pr braces in 
our Separation Logic notation. 

Cminor's integer equality operator, which wc will write as e\ == e-i, applies 
to integers or pointers, but in several cases it is "stuck" (expression evaluation 
gives no result): when comparing a nonzero integer to a pointer; when comparing 

Vundef or Vfloat(.x) to anything. Thus we can write the assertion |~e == e] exp r 
(or just write e == e) to test that e is a defined integer or pointer in the current 
state, and there is a similar operator e\ *== e2- 

Finally, we have the usual Separation Logic singleton "maps-to" , but anno- 

ch 

tated with a chunk-type ch. That is, e\ i— > e2 means that e\ evaluates to v\, 62 
evaluates to V2 , and at address v\ in memory there is a defined value V2 of the 
given chunk-type. Let us note that in this definition, defined (vi) is implied by 
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the third conjunct, defined^) is a design decision. We could leave it out and 
have a slightly different Separation Logic. 



The Hoare Sextuple. Cminor has commands to call functions, to exit (from 
a block), and to return (from a function). Thus, we extend the Hoare triple 
{P} s {Q} with three extra contexts to become r;R;Bh- {P}s{Q} where: 
r : assert describes context-insensitive properties of the global environment; 
R : list va I ^assert is the return environment, giving the current function's post- 
condition as a predicate on the list of returned values; and 
B : nat — > assert is the block environment giving the exit conditions of each 
block statement in which the statement s is nested. 

Most of the rules of sequential Separation Logic are given in Fig. 4. In this 
paper, we omit the rules for return and call, which are detailed in the full tech- 
nical report. Let us note that the r context is used to update global function 
names, none of which is illustrated in this paper. 

P^P' r-,R;B h {P'}s{Q'\ Q'^-Q r , r , 

— — r;R;By- {P}skip{P} 



r;R;B h {P}s{Q} 

r;R;Bh {P} Sl {P} r-R-BY- {P}s 2 {Q} 
r;R;B h {P}si;s 2 {Q} 

p' = p a [x:=v] P = (3v.ei}.v A \a.Qa[:=p']) 
r;R;BV- {P}x := e{Q} 

pure(e) pure(e2) P = (e h-> e 2 A defined(ei)) 

r;J?;Sr-{P}[e] c;i :=ei{ e ^e 1 } 

pure(e) Z 1 ; R; B h {P A e}s 1 {Q} R; B h {P A ^e}s 2 {Q} 

r;R;B\- {P}if e then 7i else s 2 {Q} 

r;R;B\- {I}s{I} r;R;Q-B\- {P}s{false} 



P;R;B\- {Jjloop s{false} r-R-Bh {Pjblock s{Q} 

r;R;Bh {B(n)}exitn{false} 

r-,R;B\- {P}s{Q} modified vars(s) n freevars(A) = 
r; (Xvl.A * R(vl))- (Xn.A * B(n)) \- {A* P}s{A * Q} 

Fig. 4. Axiomatic Semantics of Separation Logic (without call and return) 
The rule for [e] cft :=ei requires the same store permission than the small-step 

ch 

rule, but in Fig. 4, the permission is hidden in the definition of e i— > C2- The 
rules for [e] ch -~ei and if e then si else S2 require that e be a pure expression. To 
reason about an such statements where e is impure, one reasons by program 
transformation using the following rules. It is not necessary to rewrite the actual 
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source program, it is only the local reasoning that is by program transformation. 

x, y not free in e, e±, Q r\R\B\- {P} x := e; y := e\\ [x] ch :=y {Q} 

r;R;Bh{P}[e] ch := ei {Q} 

x not free in s 1; s 2 , Q r; R;B h {P} x := e; if a; then Si elses 2 {Q} 

r;R;B\- {P} if e then Sl else s 2 {Q} 

The statement exiti exits from the (i + l) th enclosing block. A block environ- 
ment B is a sequence of assertions So, B\, . . . , B^-i such that (exit?) is safe as 
long as the precondition Bi is satisfied. We write nile for the empty block envi- 
ronment and B' = Q ■ B for the environment such that B' = Q and B' i+1 = Bi. 

Given a block environment B, a precondition P and a postcondition Q, the 
axiomatic semantics of a (blocks) statement consists in executing some state- 
ments of s given the same precondition P and the block environment Q ■ B 
(i.e. each existing block nesting is incremented). The last statement of s to be 
executed is an exit statement that yields the false postcondition. An (exitn) 
statement is only allowed from a corresponding enclosing block, i. e. the precon- 
dition B(n) must exist in the block environment B and it is the precondition of 
the (exitn) statement. 



Frame Rules. The most important feature of Separation Logic is the frame rule, 
usually written , 

{A *P}s{A *Q} 

The appropriate generalization of this rule to our language with control flow is 
the last rule of Fig. 4. We can derive from it a special frame rule for simple 
statements s that do not exit or return: 

\JR,B.{r;R;B h {P}s{Q}) modified vars(s) n freevars(A) = 
r ; i?;Bh {A*P}s{A*Q} 

Free Variables. We use a semantic notion of free variables: x is not free in as- 
sertion A if, in any two states where only the binding of x differs, A gives the 
same result. However, we found it necessary to use a syntactic (inductive) defini- 
tion of the variables modified by a command. One would think that command c 
"modifies" x if there is some state such that by the time c terminates or exits, x 
has a different value. However, this definition means that the modified variables 
of if false then B else C are not a superset of the modified variables of C; 
this lack of an inversion principle led to difficulty in proofs. 



Auxiliary Variables. It is typical in Hoare Logic to use auxiliary variables to 
relate the pre- and postconditions, e.g., the variable a in {x = a} x := x + 1 {x = 
a + 1}. In our shallow embedding of Hoare Logic in Coq, the variable a is a 
Coq variable, not a Cminor variable; formally, the user would prove in Coq 
the proposition, Va, (-T; R;B h {P}s{Q}) where a may appear free in any of 
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r, R, B, P, s, Q. The existential assertion 3z.Q is useful in conjunction with this 
technique. 

Assertions about functions require special handling of these quantified aux- 
iliary variables. The assertion that some value / is a function with precondition 
P and postcondition Q is written / : VxiVa^ ■ ■ - Y x n, {P}{Q} where P and Q 
are functions from value-list to assertion, each V is an operator of our separation 
logic that binds a Coq variable Xj using higher-order abstract syntax. 

Application. In the full technical report [4], we show how the Separation Logic 
(i.e. the rules of Fig. 4) can be used to prove partial correctness properties of 
programs, with the classical in-place list-reversal example. Such proofs rely on 
a set of tactics, that we have written in the tactic definition language of Coq, to 
serve as a proof assistant for Cminor Separation Logic proofs [3] . 

5 Soundness of Separation Logic 

Soundness means not only that there is a model for the logic, but that the 
model is the operational semantics for which the compiler guarantees correctness! 
In principle we could prove soundness by syntactic induction over the Hoare 
Logic rules, but instead we will give a semantic definition of the Hoare sextuple 
r;R; B h {P} s {Q}, and then prove each of the Hoare rules as a derived lemma 
from this definition. 

A simple example of semantic specification is that the Hoare Logic P =>■ Q 
is defined, using the underlying logical implication, as V<Pa. P&a => QWa. 
From this, one could prove soundness of the Hoare Logic rule on the left (where 
the => is a symbol of Hoare Logic) by expanding the definitions into the lemma 
on the right (where the is in the underlying logic), which is clearly provable 
in higher-order logic: 

P^Q Q^R Wa.(P<Pa Q&a) Wa.(Q<Pa R&a) 

P R Wajma => m~a) 

Definition 4. (a) Two states a and a' are equivalent (written as a = a') if 
they have the same stack pointer, extensionally equivalent environments, iden- 
tical footprints, and if the footprint-visible portions of their memories are the 
same, (b) An assertion is a predicate on states that is extensional over equivalent 
environments (in Coq it is a dependent product of a predicate and a proof of 
extensionality) . 

Definition 5. For any control n, we define the assertion safe k to mean that 
the combination of k with the current state is safe: 

safe k =def \&a.Va'. (a = a' => \P h safe (a', k)) 

Definition 6. Let A be a frame, that is, a closed assertion (i.e. one with no free 
Cminor variables). An assertion P guards a control K in the frame A (written 
as P Ua k) means that whenever A* P holds, it is safe to execute k. That is, 

P Da k ~dcf A * P =>■ safe k. 
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We extend this notion to say that a return- assertion R (a junction from value- 
list to assertion) guards a return, and a block-exit assertion B (a function from 
block-nesting level to assertions) guards an exit: 

RMak —del Vvl.R(vl) Ua return vl ■ k =dcf Vn.-B(n) Ua exit n ■ n 

Lemma 4. // P \2a si ■ s 2 ■ k then P Ua (si; s 2 ) ■ K - 

Lemma 5. // R EU k then Vs, R 0,4 s • k. If B EjU k then Vs, B Sa s ■ k. 

Definition 7 (Frame). A frame is constructed from the global environment r, 
an arbitrary frame assertion A, and a statement s, by the conjunction of T with 
the assertion A closed over any variable modified by s: 

frame(T, A, s) =a e f r * closemod(s, A) 

Definition 8 (Hoare sextuples). The Hoare sextuples are defined in "contin- 
uation style, " in terms of implications between continuations, as follows: 



r;R;B\-{P}s{Q} = def VA, K. 

R Eframe(r,A,s) K A B Bf r ame(r,A,s) K A Q Df rame (r,A,s) K P Dframe(_T,A,s) 



From this definition we prove the rules of Fig. 4 as derived lemmas. 

It should be clear from the definition — after one gets over the backward 
nature of the continuation transform — that the Hoare judgment specifies partial 
correctness, not total correctness. For example, if the statement s infinitely loops, 
then the continuation (a, s ■ k) is automatically safe, and therefore P \3a s • k 
always holds. Therefore the Hoare tuple r;R;B h {P}s{Q} will hold for that 
s, regardless of P, R, B, P, Q. 

Sequence. The soundness of the sequence statement is the proof that if the 
hypotheses Hi : r- R; B h {P} si {P'} and H 2 : r ; R; B h {P 1 } s 2 {Q} hold, 
then we have to prove Goal : _T; R\B h {P} si; S2 {Q} (see Fig. 4). If we unfold 
the definition of the Hoare sextuples, Hi, H2 and Goal become: 

^— ^ ^ H i( i = l,2 

Uframe(r,A,Si) s i ' K i 

R Hframe(r,A,(s i; s 2 )) « -B 0frame(r, J 4,(s 1 ;s 2 )) K Q □frame(r,A,(si;s 2 )) « 

(VA, k) — — 

P Gfr ame (r,A,(,s 1 ;s 2 )) (si; 82) ■ k 

We prove P Df rame (r,A,( Si;S2 )) (si; s 2 ) ■ k using Lemma 4: 4 

i?0fc BUk RQk BQk QDk 

-Lm. 5 — ; — Lm. 5 — ; H2 



R s 2 ■ k B s 2 ■ k P'Us 2 -k 

PUs 1 -s 2 -k 

Lm. 4 



PU (si;s 2 ) • fc 



4 We will elide the frames from proof sketches by writing □ without a subscript; 
this particular proof relies on a lemma that closemod(si, closemod((si; S2), A)) = 
closemod((si; S2), A). 
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Loop Rule. The loop rule turns out to be one of the most difficult ones to prove. A 
loop continues executing until the loop-body performs an exit or return. If loops 
executes n steps, then there will be or more complete iterations of n\, n^, ■ ■ ■ 
steps, followed by j steps into the last iteration. Then either there is an exit 
(or return) from the loop, or the loop will keep going. But if the exit is from an 
inner-nested block, then it docs not terminate the loop (or even this iteration). 
Thus we need a formal notion of when a statement exits. 

Consider the statement s = if b then exit 2 else (skip; x := y), executing in state 
cr. Let us execute n steps into s, that is, \- {cr, s ■ k) i — > n (a', k'). If n is small, 
then the behavior should not depend on k; only when we "emerge" from s is 
k important. In this example, if p a b is a true value, then as long as n < 1 the 
statement s can absorb n steps independent of k; if p a b is a false value, then s can 
absorb up to 3 steps. To reason about absorption, we define the concatenation 
K\ o k 2 of a control prefix K\ and a control «2 as follows: 
Kstop o k =dcf « (Kblock k') o k =dcf Kblock (k' o k) 

(s • k') o k =def s ■ (k' o k) (Kcall xl f sp p k') o k =d e f Kcall xl f sp p (k' o k) 

Kstop is the empty prefix; Kstop o k does not mean "stop," it means k. 

Definition 9 (absorption). A statement s in state a absorbs n steps (written 
as absorb(n, s, a)) iff^j < n. 3/c prc fl x .3fT'. Vk. & \- {cr, s • k) i — > J {cr', /t pre fix ° k). 

Example 1. An exit statement by itself absorbs no steps (it immediately uses its 
control-tail), but block (exit 0) can absorb the 2 following steps: 
W h (a, block (exit 0) • n) i — > (a, exit • Kblock k) — > (cr, k) 

Lemma 6. 1. absorb(0, s, a). 

2. absorb(n + 1, s, a) => absorb(7i, s, cr). 

3. If -iabsorb(?i, s, a), then 3i < n.absorb(z, s, a) A ^absorb(i + 1, s, a). We say 
that s absorbs at most i steps in state a. 

Definition 10. We write (s; ) n s' to mean s; s; 

r;R;B\- {I}s{I} 



Lemma 7. 



r;R;B\- {/}(s;) n loopskip{false} 



Proof. For n = 0, the infinite-loop (loop skip) satisfies any precondition for par- 
tial correctness. For n + 1, assume k, RB k, B| k; by the induction hypothesis 
(with and BMk) we know iTJ (s; )™loop skip-K. We have i?@ (s; )™loop skip-K 
and B (s; )™loop skip • k by Lemma 5. We use the hypothesis -T; R; B h {I}s{I} 
to augment the result to I U (s; (s; )" loop skip) • k. ■ 

r;R-BV- {I}s{I} 

Theorem 1. 



r;R;B\- {/}loops{false} 



Proof. Assume k, R H k, B H k. To prove I Q loops • k, assume a and la 
and prove safe (cr, loop s • k). We must prove that for any n, after n steps we 
are not stuck. We unfold the loop n times, that is, we use Lemma 7 to show 
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safe (a, (s; )™loop skip • k). We can show that if this is safe for n steps, so is 
loop s ■ k by the principle of absorption. Either s absorbs n steps, in which case 
we are done; or s absorbs at most j < n steps, leading to a state a 1 and a control 
(respectively) K pr efix ° (s; )" _1 loopskip • n or K pr efix ° loops • k. Now, because s 
cannot absorb j + 1 steps, we know that either K pre fi x is empty (because s has 
terminated normally) or K pre fi x starts with a return or exit, in which case we 
escape (resp. past the loop skip or the loops,) into k. If n pre fi x is empty then we 
apply strong induction on the case n — j steps; if we escape, then (a', k) is safe 
iff (er, loops • k) is safe. (For example, if j — 0, then it must be that s = return 
or s = exit , so in one step we reach K pre fi x o (loop s • k) with n pre fi x = return or 

f^ P reftx — exit .) I 

6 Sequential Reasoning about Sequential Features 

Concurrent Cminor, like most concurrent programming languages used in prac- 
tice, is a sequential programming language with a few concurrent features (locks 
and threads) added on. We would like to be able to reason about the sequential 
features using purely sequential reasoning. If we have to reason about all the 
many sequential features without being able to assume such things as dctermi- 
nacy and sequential control, then the proofs become much more difficult. 

One would expect this approach to run into trouble because critical assump- 
tions underlying the sequential operational semantics would not hold in the 
concurrent setting. For example, on a shared-memory multiprocessor we can- 
not assume that (x:=x+l; x:=x+l) has the same effect as (x:=x+2); and on 
any real multiprocessor we cannot even assume sequential consistency — that the 
semantics of n threads is some interleaving of the steps of the individual threads. 

We will solve this problem in several stages. Stage 1 of this plan is the current 
paper. Stages 2, 3, and 4 are work in progress; the remainder is future work. 

1. We have made the language, the Separation Logic, and our proof extensible: 
the set of control-flow statements is fixed (inductive) but the set of straight- 
line statements is extensible by means of a parameterized module in Coq. 
We have added to each state a an oracle which predicts the meaning of the 
extended instruction (but which docs nothing on the core language) . All the 
proofs we have described in this paper are on this extensible language. 

2. We define spawn, lock, and unlock as extended straight-line statements. We 
define a concurrent small-step semantics that assumes noninterference (and 
gets "stuck" on interference). 

3. From this semantics, we calculate a single-thread small-step semantics equip- 
ped with the oracle that predicts the effects of synchronizations. 

4. We define a Concurrent Separation Logic for Cminor as an extension of the 
Sequential Separation Logic. Its soundness proof uses the sequential sound- 
ness proof as a lemma. 

5. We will use Concurrent Separation Logic to guarantee noninterference of 
source programs. Then (x:=x+l; x:=x+l) will have the same effect as (x:=x+2). 
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6. We will prove that the Cminor compiler (CompCert) compiles each footprint- 
safe source thread into an equivalent footprint-safe machine-language thread. 
Thus, nonintcrfcring source programs will produce noninterfering machine- 
language programs. 

7. We will demonstrate, with respect to a formal model of weak-mcmory- 
consistency microprocessor, that noninterfering machine-language programs 
give the same results as they would on a sequentially consistent machine. 

7 The Machine-checked Proof 

We have proved in Coq the soundness of Separation Logic for Cminor. Each 
rule is proved as a lemma; in addition there is a main theorem that if you prove 
all your function bodies satisfy their pre/postconditions, then the program "call 
main()" is safe. We have informally tested the adequacy of our result by doing 
tactical proofs of small programs [3] . 
Lines Component 

41 Axioms: dependent unique choice, relational choice, extensionality 
8792 Memory model, floats, 32-bit integers, values, operators, maps (ex- 
actly as in CompCert [12]) 
4408 Sharable permissions, Cminor language, operational semantics 

462 Separation Logic operators and rules 
9874 Soundness proof of Separation Logic 
These line counts include some repetition of specifications (between Modules 
and Module Types) in Coq's module system. 

8 Conclusion 

In this paper, we have defined a formal semantics for the language Cminor. It 
consists of a big-step semantics for expressions and a small-step semantics for 
statements. The small-step semantics is based on continuations mainly to allow 
a uniform representation of statement execution. The small-step semantics deals 
with nonlocal control constructs (return, exit) and is designed to extend to the 
concurrent setting. 

Then, we have defined a Separation Logic for Cminor. It consists of an as- 
sertion language and an axiomatic semantics. We have extended classical Hoare 
triples to sextuples in order to take into account nonlocal control constructs. 
From this definition of sextuples, we have proved the rules of axiomatic seman- 
tics, thus proving the soundness of our Separation Logic. 

We have also proved the semantic equivalence between our small-step seman- 
tics and the big-step semantics of the CompCert certified compiler, so the Cminor 
programs that we prove in Separation Logic can be compiled by the CompCert 
certified compiler. We plan to connect a Cminor certified compiler directly to 
the small-step semantics, instead of going through the big-step semantics. 

Small-step reasoning is useful for sequential programming languages that will 
be extended with concurrent features; but small-step reasoning about nonlocal 
control constructs mixed with structured programming (loop) is not trivial. We 
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have relied on the determinacy of the small-step relation so that we can define 
concepts such as absorb(n, s, a). 
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